We were starting to get problems with some of these migrations, referring to models that have been deleted or depending on migrations which depended on fixtures, which were later changed or deleted (note to self: migrations should never reference fixtures). So I've squashed the migrations here which makes it much simpler and more robust. I'd really like to get the squashed version into Quince. If possible, I'd like to squash the migrations in oel_tagging too but that would be a separate PR.

I'm confused.. The ContentAuthorTaxonomy and ContentOrganizationTaxonomy models have also been deleted, so I would expect them to cause problems just like the ContentLanguageTaxonomy does now? No worries if they're not, I'm just curious.

Ach.. I'm afraid this line caused an issue when I was testing openedx/openedx-learning#95 :(

Changing it to this fixes the issue, but means we need to merge/tag openedx/openedx-learning#95 first:

Here's the steps I took:

1. Zero-ed the migrations oel_tagging and content_tagging, and ensured all the tables for these apps were dropped.
2. Checked out edx-platform master (b353019), and installed openedx-learning v0.2.0
3. Ran migrations, which applied fine:

   $ ./manage.py lms migrate
   Running migrations:
     Applying oel_tagging.0001_initial... OK
     Applying oel_tagging.0002_auto_20230718_2026... OK
     Applying oel_tagging.0003_auto_20230721_1238... OK
     Applying oel_tagging.0004_auto_20230723_2001... OK
     Applying oel_tagging.0005_language_taxonomy...Installed 185 object(s) from 1 fixture(s) OK
     Applying content_tagging.0001_initial... OK
     Applying content_tagging.0002_system_defined_taxonomies... OK
     Applying content_tagging.0003_system_defined_fixture... OK
     Applying content_tagging.0004_system_defined_org... OK
     Applying content_tagging.0005_auto_20230830_1517... OK
     Applying content_tagging.0006_simplify_models... OK
     Applying oel_tagging.0006_alter_objecttag_unique_together... OK
     Applying oel_tagging.0006_auto_20230802_1631... OK
     Applying oel_tagging.0007_tag_import_task_log_null_fix... OK
     Applying oel_tagging.0008_taxonomy_description_not_null... OK
     Applying oel_tagging.0009_alter_objecttag_object_id... OK
     Applying oel_tagging.0010_cleanups... OK
   

4. Checked out this branch and installed the branch from Squash Tagging Migrations [FC-0030] openedx-learning#95.
5. Applied migrations, which errored out:

   django.db.migrations.exceptions.InconsistentMigrationHistory: Migration content_tagging.0001_squashed is applied before its dependency oel_tagging.0012_language_taxonomy on database 'default'.
   

6. Made the above recommended change, and was able to proceed with applying the migrations:

   $ ./manage.py lms migrate
   Running migrations:
     Applying oel_tagging.0011_remove_required... OK
     Applying oel_tagging.0012_language_taxonomy... OK
     Applying content_tagging.0007_system_defined_org_2... OK
   

7. Tested rollback, which worked OK¹

   $ ./manage.py lms migrate content_tagging zero
   $ ./manage.py lms migrate oel_tagging zero
   

8. Tested applying the squashed migrations, also worked fine:

   $ ./manage.py lms migrate
   Running migrations:
     Applying oel_tagging.0001_squashed... OK
     Applying oel_tagging.0012_language_taxonomy... OK
     Applying content_tagging.0001_squashed... OK
     Applying content_tagging.0007_system_defined_org_2... OK   
   

¹ I always get errors about the named indexes (content_tag_taxonom_70d60b_idx, content_tag_taxonom_b04dd1_idx, oel_tagging_taxonom_5e948c_idx, etc.) when rolling back migrations ("Cannot drop index 'whatever_idx': needed in a foreign key constraint"). I've seen this before these migrations were squashed, and I don't know why it happens. To get around it, I comment out the AddIndex and AlterUniqueTogether lines in the squashed migrations before rolling back.